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REMARKS 



This amendment is responsive to the Office Action dated February 1, 2006. Applicant 
has amended claims 1,21, 30, 31, 36-40 and 43. Claims 1-28 and 30-43 remain pending. 

Claim Rejection Under 35 U.S.C. § 103 

In the Office Action, the Examiner rejected claims 1-28 and 30-43 under 35 U.S.C. 
103(a) as being unpatentable over Moussa et al. (USPN 6,742,043) in view of AAPA, in further 
view of eekim.com, CGI Programming Slides, 1996. Applicant respectfully traverses the 
rejection to the extent such rejections may be considered applicable to the claims as amended. 
The applied references fail to disclose or suggest the inventions defined by Applicant's claims, 
and provide no teaching that would have suggested the desirability of modification to arrive at 
the claimed invention. 

Claims 1-28, 31-39 and 43 

Applicant has amended claim 1 to direct the claim to an embodiment that requires, after 
sending an acknowledgement to a remote client and prior to processing a request to identify the 
requested resource, sending a pre-determined message to initiate a page rendering process at the 
remote client. 

Applicant directs the Examiner to FIG. 5 of the present application, reproduced below, 
which illustrates the claimed embodiment: 
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FIG. 5 of the present application shows an embodiment in which a client 202 issues a request 520 
for a web resource. In response, a device, such as a server 204, issues an acknowledgement 524. 
See, e.g., pg 8, In. 20 - pg. 9, In. 4. After issuing the acknowledgement, the device issues an 
Initial Page Rendering (IPR) message 521 to the device. As shown in FIG. 5, the device issues 
the IPR message 521 after the acknowledgement, and prior to processing the request to determine 
the requested resource. The IPR message 521 is a generic message that causes the client to 
initiate the page rendering process. Other clarifying claim amendments have been made to 
claims 21, 31 and 43. 

In rejecting claim 1 in its previous form, the Examiner cited Moussa in view of 
Applicant's Background (AAPA), in further view of Eekim. As discussed in Applicant's 
previous responses, Moussa describes a proxy server that reformats web content in a particular 
way under certain conditions as determined by the operator of the proxy server. 1 Specifically, the 
proxy server retrieves web content requested by a client and, after retrieving the content, 
reformats it into a suitable format for the requesting client, and then forwards the reformatted 
web content to the requesting client. (See, col. 2, In. 35-65, stating "When client 2 requests a web 
page involving an image, WebTV server 6 retrieves the size information from its cache, rewrites 
the HTML of the web page to include the size information, and then relays the HTML on to 
client 2.") 

Moussa makes very clear that, when client 2 requests a web page involving an image, 
WebTV server 6 first processes the request to identify the identified web page and image, 
retrieves the size information for that particular image from its cache, rewrites the HTML of the 
web page to include the size information, and then relays the HTML on to client 2. Thus, for a 
given client request, the Moussa proxy server must first process the request to first determine the 
requested web resource and related image. Only thereafter does the Moussa proxy server return 
size information for that particular image returned to the client to reduce latency. 

The Examiner recognized that Moussa does not teach, prior to processing the request, 
sending any form of a pre-determined message to initiate a page rendering process at the remote 
client. Office Action, pg. 3. However, the Examiner cited AAPA as suggesting a pre-determined 
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message to initiate a page rendering process at the remote client. In particular, the Examiner 
cited Applicant's Background, FIG. 1, showing an ACK 124 sent in response to a request. 

Applicant disagrees with the Examiner's characterization of ACK 124 as a pre- 
determined message that initiates a page rendering process at the remote client. Moreover, the 
Examiner's characterization is directly contrary to the language of AAPA, which states that only 
after reply 122 is subsequently received does client 102 initiate a page rendering process by 
wiping any previously displayed web resource from the client browser. Applicant's Background, 
pg. 4, 11. 18-20. Reply 122 is sent, of course, after the initial request 120 is processed. Thus, 
there is no teaching or suggestion in AAPA that ACK 124 operates to initiate a page rendering 
process at the client device, and the Examiner is likely incorrect in his conclusion relative to the 
operation of ACK 124. 

Nevertheless, as discussed above, Applicant has amended claim 1 to direct the claim to an 
embodiment in which the initial page rendering (IPR) message is sent after sending an 
acknowledgement, and prior to processing the request to determine the requested resource. 
Based on this clarifying amendment, it should be clear that simply sending an acknowledgement 
(as described in AAPA), does not teach or suggest, after sending the acknowledgment to the 
remote client and prior to processing the request to identify the requested web resource, sending a 
pre-determined message to initiate a page rendering process at the remote client. For at least 
these reasons, Moussa in view of AAPA fails to teach or suggest the elements of claim 1 . 

In the Office Action, the Examiner also referred to Eekim. Eekim is a two page 
document cited by the Examiner that describes the basic format of a standard hypertext protocol 
(HTTP) response that is sent after processing a request for a resource . Eekim describes the 
HTTP response itself as including a portion (response header) that describes the type of content 
carried by the remainder of that same response. On pg. 2, Eekim states that after processing a 
client request, the server outputs a response message that includes: (1) headers carrying the 
MIME Type, (2) a blank line, and (3) the requested data (content). None of the teachings of 
Eekim teach or suggest sending any form of a message to the client after sending the 
acknowledgment and prior to processing the request. To the contrary, Eekim teaches first 
processing the request to identify the requested resource then, when formatting the response, 
including data to identify the type of content carried by that response. Eekim adds nothing to 
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address the deficiencies of Moussa or AAPA. None of these references, either singularly or in 
combination, teach or suggest sending any form of a message, after acknowledging a request and 
prior to processing the request, where the message initiates a page rendering process on the 
client. 

For at least these or similar reasons, Moussa in view of AAPA and in further view of 
Eekim fails to establish a prima facie case for non-patentability of Applicant's claims 1-28, 31-39 
and 43 under 35 U.S.C. 103(a). Withdrawal of this rejection is requested. 

Claims 30 and 40-42 

Applicant has amended independent claims 30 and 40 to direct the claims to an 
embodiment in which an intermediate device, prior to forwarding one or more of the requests to 
the web server, sends a pre-determined message to initiate a page rendering process at the remote 
client. Independent claims 30 and 40 further requires that after the page rendering message is 
sent, forwarding the requests to the web server and, after forwarding the request to the web 
server, receiving an acknowledgement and a reply from the server for each of the requests. 

Applicant directs the Examiner to FIG. 9 of the present application, reproduced below: 
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Fig. 9 

FIG. 9 of the present application shows an embodiment in which a client issues a request 920 for 
a web resource. In response, an intermediate acceleration device 618 intercepts the request 920 
and immediately issues an IPR message 921 to initiate page rendering at the client. After issuing 
IPR message 921, the intermediate acceleration device forwards the request 920 to the server. 
The intermediate device then subsequently receives and forwards acknowledgement 924 and 
reply 922 from the server to the client. See, e.g., pg 15, 11. 1-17. 

For reasons similar to those set forth above, none of these references, either singularly or 
in combination, teaches or suggests, prior to forwarding one or more of the requests to the web 
server, sending any form of a message from an acceleration device to a client to initiate a page 
rendering process on the client, and then subsequently forwarding an acknowledgement and a 
reply from the server to the client. 
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For at least these reasons, Moussa in view of AAPA and in further view of Eekim fails to 
establish a prima facie case for non-patentability of Applicant's claims 30 and 40-42 under 35 
U.S.C. 103(a). Withdrawal of this rejection is requested. 



All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 



CONCLUSION 



Date: 



By: 




8425 Seasons Parkway, Suite 105 



Reg. No.: 41,312 



St. Paul, Minnesota 55125 
Telephone: 651.735.1100 
Facsimile: 651.735.1102 
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